CS125 : Introduction to Computer Science 


Lecture Notes #4 
Expressions, Statements, and Style 


(©)2000, Jason Zych 


Expressions — the “phrases” of a computer language. 


An expression is a code segment that can be evaluated 
to produce a value. 

Expressions are not always complete units of work — in 
the cases where they are not, they are used in code seg- 
ments that are complete units of work — and those code 
segments are generally trying to use the value that the 
expression evaluates to. 


Expression examples: 


e2+ 2 

eslope * x + intercept 
e 5280 * number0fMiles 
e total/numScores 


eat+b-ct+td-e 





Statements — the “sentences” of a computer language 


A statement is a code segment that produces a com- 
plete unit of work. Every statement in a program is fol- 
lowed by a semicolon. 

We have already seen declaration statements and as- 
signment statements. An assignment statement will gen- 
erally have an expression on its right hand side. ‘That 
expression gets evalutated to produce a value, and that 
value gets stored in the variable on the left side of the 
assignment statement. 


Statement examples: 
ec=2+ 2; 


ex = 5; 


ey = slope * x + intercept; 


eint b; 

e numberO0fFeet = 5280 * numberO0fMiles; 
We will be looking at many other kinds of statemensts 
besides declaration and assignment statements. State- 
ments are the building blocks of a computer program - 


you list them one after the other, and they are run one 
by one until the program has completed. 
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Operators — (some of) the “verbs” of a computer 
language 


Operators are symbols that indicate some kind of ac- 
tion is to be performed. ‘These are usually very simple 
actions, such as: 


e+: addition 

e — : subtraction 

e * : multiplication 
e / : division 

e /,: modulus 

e ++ : increment 

e -- : decrement 

e =: assignment 


One symbol can mean different things in different con- 
texts. ‘This context depends on the type of the operands. 
For example, a + b is compiled to a different collection 
of machine language instructions depending on whether 
a and b are floating-point types, or integer types. In fact, 
a and b could be different types...and the language needs 
to have a rule about what happens in that case as well. 





Example 1 — integer calculations 


public class Examplel 


if 


} 


public static void main(String[] args) 


{ 
int weightedQuantity ; 
int examl, exam2; 


exami = 60; 
exam2 = 70; 
weightedQuantity = 20 * exami + 80 * exam2; 


// weighedQuantity is now 6800. 


e 20 * examt is integer * int which is an int 
e 80 * exam? is integer * int which is an int 
e The addition is int + int which is an int 


e The assignment is int = int, which is okay. 


Example 2 - a slight problem with division 


public class Example2 
if 
public static void main(String[] args) 
{ 
int sum, average; 
int examl, exam2; 


exami = 75; 

exam2 = 90; 

sum = exami + exam?2; 
average = sum/2; 


// average is now...82, not 82.5 


} 


e exami + exam2 is int + int which is an int 


e The division is int/int which is an int — result is 
truncated!! 


e The assignment is int = int, which is okay. Result: 
82 


Example 3 - change average to double 


public class Example3 
af 
public static void main(String[] args) 
{ 
int sum; 
double average; 
int examl, exam2; 


exami = 75; 

exam2 = 90; 

Sum = exami + exam?2; 
average = sum/2; 


// average which is now...what? 


} 


e exami + exam2 is int + int which is an int 


e The division is int/int which is an int — result is 
truncated!! 


e The assignment is double = int, which is okay. The 
int is automatically converted to a double...which is 
why we get 82.0 and not 82. 


Example 4 — fix #1: change sum to double 


public class Example4 
af 


public static void main(String[] args) 
{ 

double sum; 

double average; 

int examl, exam2; 


exami = 75; 

exam2 = 90; 

Sum = exami + exam?2; 
average = sum/2; 


// average is now 82.5. 


} 


e exami + exam2 is int + int which is an int 


e The division is double/int which is a double — fi- 
nally, result is not truncated!! 


e The assignment is double = double, which is okay. 
The result: 82.5 


Example 5 — fix ##2: change int literal to double literal 


public class Exampled 
af 


public static void main(String[] args) 
{ 

int sum; 

double average; 

int examl, exam2; 


exami = 75; 

exam2 = 90; 

sum = exami + exam?2; 
average = sum/2.0; 


// average is now 82.5. 


} 


e exami + exam2 is int + int which is an int 


e The division is int/double which is a double — 
again, result is not truncated!! 


e The assignment is double = double, which is okay. 
The result: 82.5 


Example 6 — fix #3: cast int to double 


public class Example6 
1 
public static void main(String[] args) 
{ 
int sum; 
double average; 
int examl, exam2; 


exami = 75; 

exam2 = 90; 

sum = exami + exam?2; 
average = (double) sum/2; 


// average is now 82.5. 


} 


e exami + exam2 is int + int which is an int 


e The cast takes the int sum and converts it to the 
corresponding double temporarily — for the purposes 
of this one operation. 


e The division is double/int which is a double — so, 
result is not truncated!! 


e The assignment is double = double, which is okay. 
The result: 82.5 


Operators have precedence — certain operators get eval- 
uated before other operators. ‘This is similar to algebra, 
where multiplication and division were performed left to 
right first, and once all the multiplications and divisions 
were completed, then addition and subtraction were per- 
formed, again from left to right. 

The class textbook (IKMR_,) discusses the arithmetic op- 
erators and a few precedence rules in chapter 2. We will 
be exploring more operators in chapter 4, and there is a 
listing of a few more operators in Appendix A.4 and a full 
list of all operators and their operator prededence rules 
in Appendix B. 











Programming Style 


While certainly it is most important to write a program 
that actually works, it is also important to write your 
code using good programming style. Doing this makes 
your code more readable and understandable, which is 
very important. 

Imagine if our “Hello World” program was written as 
follows: 


public class HelloWorld { public 
static void main(String[] args) 
{ System.out.println("Hello World!"); }} 


That is legal! The compiler can understand this! But 
you cannot. 

Think of the text of a program as being a bunch of 
characters one after another in a pipe. The compiler reads 
these characters in one by one, and all spaces, blank lines, 
and tab characters (collectively known as “whitespace” ) 
are discarded by the compiler. 

So, you can put in as many blanks as you want. They 
only serve to help you (and others) read your program, 
but they don’t add to your program size because the com- 
piler gets rid of them. 


Style component #1: Indentation 


Proper indentation is arguably the single most impor- 
tant thing you can do to make your programs readable. 
There are various “indentation standards” which vary 
slightly, but the general rule of thumb they are all based 
on is that stuff inside braces should be moved to the right 
a few spaces (three is a good choice). 


Wrong: 


public class HelloWorld 

{ 

public static void main(String[] args) 
{ 

System.out.println("Hello World!") ; 

t 

F 


The first thing you need to do is realize that it would be 
easier to tell what code was inside the class if that code 
was indented three spaces. (This will be even more im- 
portant when we starting adding other methods besides 
main to a class.) 


Better, but still not right: 


public class HelloWorld 


{ 
public static void main(String[] args) 
{ 
System.out.println("Hello World!") ; 
t 
t 


The second thing to realize is that, likewise, it will be 
easier to read the code inside main if that code is indented 
three spaces. Not three spaces from the left of the screen, 
but three spaces from where the braces of the method 
are! That is six spaces total. 


Correct: 


public class HelloWorld 


{ 
public static void main(String[] args) 
{ 
System.out.println("Hello World!") ; 
t 
t 


Now, it is very easy to visually pick out with one glance 
where the class begins and ends, what code is inside it, 
where the method begins and ends, and what code is 
inside it. 








A slight variation on this is that some people like to 
put the open brace on the same line as the Java syntax 
tool it is starting: 


Also correct: 


public class HelloWorld { 
public static void main(String[] args) { 
System.out.println("Hello World!") ; 
t 


Since the word public lines up with the closing brace, 
you still have the same kind of visual structure. It’s a bit 
harder to see it, since the code is crushed together a bit 
more, but on the other hand, you can fit more code in the 
viewing window at once. Some people think this tradeoff 
is worth it and others (myself among them) don’t. You 
can make your own choice. 


That is what was meant by “indentation standards” — 
there are slightly different ways of doing things. To give 
another example, some people indent three spaces, some 
preter five. You should indent at least three but you don’t 
want to indent so many spaces that your code runs off the 
end of the page. 


You can use whichever variation you prefer — just be 
consistent!!! 





MP Alert — please don’t use a 10-space tab as your 
indentation choice. Even if you don’t mind reading code 
that runs off the end of the page and wraps around the 
left side again like a Pac-Man game, the graders will have 
difhculty reading that code and will likely grade you down 
on style points. A good rule of thumb is to keep your line 
lengths at a maximum of about 70 characters, or 80 at 
absolute most. As we do things that risk reaching that 
length even with 3- or 5- space indentation, we will talk 
about additional readability techniques to avoid wrapping 
around the end of a 70- or 80- line page. 


Style component #42: Descriptive variable names 


As we have already discussed, it is a lot easier to quickly 
figure out what a given chunk of code is doing if the vari- 
ables in that code have been given names that describe 
what data they hold. 


Unclear: 


c=atb; 


Much better: 


totalScore = exami + exam2; 





With relatively few exceptions — using single letters for 
variable names tends to be a bad idea. Even a short 
4- or 5-character abbreviation of a longer word is more 
descriptive than a or G or q. 


Style component 7#£3: Commenting 


Indentation makes it easy to read your code; descriptive 
variable names make it easy to tell what those variables 
are for. However, not every collection of statements has 
an immediately-decipherable purpose even if you know 
what each of the variables holds. In addition, it often 
helps to explain the general purpose of a particular file, 
or the individual major divisions of code within that file. 


So, for the purposes of documentation, Java provides 
syntax for commenting our code. Comments are basi- 
cally just text descriptions of whatever it is you want to 
describe or explain — the purpose of the file, a quick sum- 
mary of the intent behind a particular section of code, or 
whatever else. We use a special Java syntax to notate 
these remarks as comments; as a result, the compiler ig- 
nores them just as it ignores extra whitespace. ‘Thus, we 
can add as many comments as we want without affect- 
ing the resultant machine code at all. The comments are 
there for the code reader’s benefit only. 


The main commenting syntax 


Most of the time, the commenting syntax you will want 
to use is the use of the “double slash”: /7. You can place 
that two-character symbol anywhere in your code, and 
anything from that point to the end of the line of text 
will be ignored by the compiler. 


Example: 


// Class: HelloWorld 


// - in control of greeting generations 
// - Written August 1999 by Jason Zych 
public class HelloWorld 
{ 
// Method: main 
// - controls main execution of program 
public static void main(String[] args) 
< 


// line prints out a greeting 
System.out.println("Hello World!") ; 


Another commenting syntax 


If you want to quickly comment out a large chunk of 
text or code, you can also surround the area as follows: 


/* <---- slash-asterisk to open comment 
whatever you want goes in here 


* / <---- asterisk-slash to close comment 


Example 2: 


/* 
Class: HelloWorld 
- in control of greeting generations 
- Written August 1999 by Jason Zych 


* / 
public class HelloWorld 
{ 
public static void main(String[] args) 
{ 
System.out.println("Hello World!") ; 
t 


Example mixing the two kinds of comments: 


/* 
Class: HelloWorld 
- in control of greeting generations 
- Written August 1999 by Jason Zych 


* / 
public class HelloWorld 
{ 
// Method: main 
// - controls main execution of program 
public static void main(String[] args) 
{ 


// line prints out a greeting 
System.out.println("Hello World!") ; 


So, when you write your MPs — and when you write 
other code as well — it will be important to keep in mind 
the elements of good coding style: 


1. Indentation 


2. Descriptive variable names 





3. Comments where needed 


Part of your MP grade will depend on writing your 
code in good style. We have a collection of guidelines 
describing what kinds of comments we will expect you to 
have in your code, and we will point that document out 
when we hand out the first MP. 


Next time: input and output statements, and tying all of 
this together. 


